Exceptions and Eventflow

Exceptions historically derive from a single-threaded, imperative model of computation. Rather than including tests for the success of subsidiary operations at every procedure level using if-then-else's, it was deemed simpler to describe problems only where they arise and where they are dealt with. The catch-throw style was transferred to C++ (and then Java), and also grafted onto the I/O structures of declarative languages such as Prolog and Haskell. However, the evolution from object-oriented to eventoriented programming and the blending of this with a declarative base has led to a rather different view of computation, one which raises new questions about the relationships among events, exceptions and interrupts. This paper looks at some of these. 1 I n t r o d u c t i o n Exception-handling originated as an extension of the idea that programmers should not have to know everything about the machine they were writing programs for, to the extent of having to write code to deal with every possible contingency all the time. For instance, a division operation with 0 as its denominator can lead to a floating point overflow; one option might be that a programmer would always have to verify the denominator being non-zero before any division. However, this is not an ideal solution. One problem is that the way such an error should be dealt with is generally very similar across most occurrences, so that a lot of code would be duplicated over and over again. Even if the code were encapsulated in a procedure, the sheer number of calls would get in the way, the nature of the algorithm being programmed would be obscured, and the code would be much harder to read. The question of levels of abstraction comes into play as well; for example, if an error occurs whenion comes into play as well; for example, if an error occurs when reading a block from a disk, an ordinary applications programmer should not need to know how many retries should be attempted before giving up. Finally, the program causing the error is often running within a particular environment, and it is seldom desirable that the environment fail with the faulty program. So, a protective envelope ought to be added to protect the system from applications within it. The questions are where it should be, what it should look like, and who should see it when. High-level (as opposed to low-level) languages were designed to contain exceptions for two reasons. On the one hand, applications programmers wanted to be able to control certain kinds of errors for themselves, or to decide what should happen when particular special conditions arose. On the other hand, as systems began to be written in higher-level languages, the people developing those systems wanted mechanisms within those languages for describing what should be done when. The current commercial state-of-the-art represented by object-oriented languages like C++ and Java uses a catch-throw semantics in which methods containing method calls define a dynamic hierarchy; if an exception is thrown at a given level, it is passed up the hierarchy until it is caught by an